As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
A Microsoft Windows Embedded operating system (OS) includes functionality that can prevent the content of a storage medium from being changed. In a typical example, it may be desirable to prevent the operating system image, which may be stored on a particular disk partition or on flash media, from being changed at runtime. To accomplish this, Windows Embedded provides a file-based write filter which operates at the file level and a block-based write filter (or enhanced write filter) that operates at the block level to redirect all writes that target a protected volume to a RAM or disk cache called an overlay. This overlay stores changes made to the operating system at runtime but is removed when the device is restarted thereby restoring the device to its original state.
FIG. 1 illustrates a how a file-based write filter 110 can be conventionally employed by an information handling system to prevent the contents of a protected volume on disk 100 from being modified. Disk 100 is intended to generally represent any type of physical storage medium (or volume). In accordance with the Windows architecture, a driver stack consisting of file system driver 111, volume manager 112, and disk driver 113 sit atop disk 100, and I/O manager 120 manages the flow of I/O requests through the driver stack. An application (not shown) can employ file/directory management application programming interfaces (APIs) 160 to invoke a service of system services 130 (e.g., by calling ReadFile, WriteFile, CreateFile, etc. on a particular file) which will result in I/O manager 120 creating an I/O request packet (IRP) for the request. This IRP will then be passed down through the driver stack.
Unlike a regular Windows operating system, a Windows Embedded operating system (such as Windows Embedded Standard “WES”) has a Write Filter that routes all I/O from the disk to an overlay in memory. As depicted in FIG. 1, file-based write filter 110 is positioned at the top of the driver stack and will therefore be able to process an IRP prior to the IRP being passed down to the lower level drivers. File-based write filter 110 can be configured to detect writes targeting a protected volume and redirect them to write filter overlay 140 that is temporarily stored in system volatile memory, rather than allowing them to be passed down the driver stack. As a result, the write will actually occur in overlay 140 rather than to disk 100. File-based write filter 110 can be further configured to detect reads that target content that was previously redirected to overlay 140 and redirect these reads to overlay 140. In this way, even though it will appear to the application that the content of disk 100 is being updated, the updates are actually being temporarily maintained in overlay 140. The contents of overlay 140 can be maintained until the operating system is restarted or until an explicit command is received to discard the contents of the overlay. A RAM disk section may also be provided in system volatile memory that is separate from write filter overlay 140. Such a separate RAM disk section may be provided for storing temporary data such as web browsing data, etc.
The size of the overlay 140 employed by the Windows file-based write filter is static and cannot be changed without rebooting. Therefore, the information handling system will be automatically rebooted if the overlay 140 becomes 90% full with data to allow sufficient memory for the Windows OS to perform required housekeeping actions before reboot. Two Microsoft standard warnings are given to the user when the size of data in overlay 140 reaches a certain level: The user is warned when the write filter is almost full (85% of filter 140 is consumed by data), and the user is warned when that the information handling system is about to reboot when overlay 140 is 90% full of data. The information handling system user at this point does not know why the system is going to reboot, nor when the system is going to reboot. The user is only notified that the system is going to reboot.
A FbwfSetCacheThreshold function allows the size of the write filter overlay 140 (in megabytes) to be specified. However, when this function is called, it has no effect on the size of the overlay 140 during the current session. Instead, a newly specified size of the overlay 140 will not be applied until the next session. By default, the size of the overlay 140 in the current Microsoft Windows Embedded operating system is 64 megabytes and can be increased up to the value of FBWF_MAX_CACHE_THRESHOLD.
The Microsoft Embedded Standard operating system (OS) (WES OS) is designed for Virtual Desktop Infrastructure (VDI) use on a thin client (TC) information handling system. It is not designed for local applications or a local browser on the TC. If a user of a TC uses WES TC for non-VDI purposes then write filter overlay consumption and rate of consumption of other local resources (such as RAM disk) by local applications such as web browser (which generates temporary data like cookies and images), media player, PDF reader and other customer applications increases. This affects the TC performance and user experience.